怎麼把菜送到顧客手上?

1. API → 餐廳的點餐窗口

   認證/授權就是窗口的身分檢查（誰可以點什麼菜）

2. OAuth2 → 規定一套「代客下單」的流程

   第三方可以在你同意下代你操作，但受限於權限範圍 scope

3. JWT → 一張可機器驗證的「通行證」

   裡面有一些資訊（payload），外面有簽名確保沒被改過

攻擊方

📌 密碼不要太簡單

1. 竊取 token（從 XSS、localStorage、未加密傳輸、惡意 App 或瀏覽器擴充）
2. 重放攻擊（replay）：攔截一次性請求後重播，造成重複交易或繞過驗證
3. 弱簽名 / alg: none 攻擊：若伺服器接受不安全的演算法或不驗證簽名，攻擊者偽造 token
4. 長期有效 token 被濫用：token exp 設很長或沒有撤銷機制，一旦被盜損害大
5. 範圍濫用（excessive scope）：授權給第三方過多權限，導致濫用
6. 錯誤 CORS / CSRF 設定：跨站可發出授權 cookie 或 header，導致未授權行為

防禦方

📌 使用 HttpOnly cookie 或安全的存儲機制

1. 驗證 JWT 簽名與 alg，使用強簽名（RS256 / ES256），不要接受 alg:none
2. Token 內容不要放敏感資料（即使是加簽也不可當機密存放）並設 exp、iat、nbf
3. 撤銷現存 access token（token rotation / revocation list）
4. 對 token exchange、token refresh設速率限制與行為偵測
5. 以 cookie 認證，設定同源政策與 SameSite
6. 以 Bearer token，要求 Authorization header 並在 server 檢查 Origin/Referer
7. 私鑰與 client secret 必須妥善存放（KMS/SEV），並定期輪換

範例

1. 接受 alg: none 的 JWT
   • 攻擊：在 token header 寫 {"alg": "none"} 並放入任意 payload，server 不驗簽就接受
   • 改法：只接受明確簽名演算法，並驗簽；使用 RS256 並驗證公鑰來源（JWKS）
2. 把 access token 存 localStorage
   • 攻擊：XSS 可讀 localStorage，竊取 token
   • 改法：若真要用 cookie，設定 HttpOnly; Secure; SameSite=Strict
3. access token 沒 exp 或過長
   • 攻擊：一旦被盜長期有效會造成重創
   • 改法：設短期限並強制 refresh；refresh token 使用 refresh rotation
4. OAuth client secret 放在前端
   • 攻擊：公開存放的 secret 被盜用
   • 改法：前端使用 public client flow（PKCE）或不在客戶端保存 secret

偵測指標

• 大量同一 token 在不同 IP/geo 被使用
• 大量失敗的 token 兌換 / refresh 嘗試
• token 頻繁 rotation / refresh（比正常頻率高）
• 異常 client_id / user agent 組合頻繁呼叫敏感 API

結論

📌 現代網路應用大量依賴 API 與 token-based 認證來支援微服務

這些機制提供便利與彈性，但也帶來新的攻擊面

token 一旦被竊取或簽名驗證不當

就能讓攻擊者冒充使用者執行高風險操作

📌 防護的關鍵在於最小權限、短期 token、強驗證與密鑰管理

同時不能忽視 API 設計與日誌監控